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(54) Permit for controliing access to services In protected memory systems 

(57) One embodiment of the present invention pro- 
vides a methcxi and an apparatus for controlling access 
to services in a protected memory system. The method 
makes use of a permit, which includes an access con- 
trol mechanism (500) that resides in a memory space 
that is protected from a user of the permit The method 
includes receiving a request for a service through a per- 
mit, the permit conprising an object (300) defined within 
an object-oriented programming system. In response to 
the request, the method activates an access control 
mechanism within the permit. This access control 
mechanism controls access to the service and resides 
in a memory space that is protected from a user of the 
permit such that the access control mechanism is trig- 
gered by invoking (502) a method (306-310) on the per- 
mit. If the access is allowed, the method accesses the 
service by performing an invocation (506) on a control- 
led object (320). This controlled object includes meth- 
ods (324-328) to perform the service, and is othenMise 
protected from the user of the permit Another variation 
of the above embodiment includes receiving, at a permit 
issuing authority, a request for the permit from an entity 
(such as a person, a computer program or a computer 
process) requiring access to the service. If the request 
includes valid authorisation information, a permit is 
issued (412) to the entity. A further variation of the 
atHve embodiment includes creating a copy of the per- 
mit and transferring the copy to an entity requiring 
access to the servica 
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Description 
BACKGROUND 

rOOOIl The present irwerrtion relates to protection i 
SLsms in'oo-rputer systems More ^eo.^^. 
the preseot inverrtion relates to a method atKl a" appa 
tor controlling access to services provided by 
olher applications in protected memory systems. 
r0002] Programming languages such as the Java 

JLmir^anguage (dereloped by SUN Miaosys- 
tems. Inc of Palo Alto. CalHornia) and associated sup- 
pXi nterfaces presently provide a reliable a«l 
S«ur? ir,f rastructure to support the transfer of an app^^ 
SSon across a computer network, and to run theappU- 
cation on a wide range of computing platforms^ 
etSise of developments such as Java, it is becoming 
fnoreasingly common to load an application, such as a 
J^ applet, from a remote sender onto a local machine, 
andtoecBcutethe application on the J^achine. 
Joo03] However, present computing sy^ems are net 
designed to allow computer applications from drtterent 
S^to interact wfth each other a cont^^^ 
so that the applications can worktogetherto acconp^|sh 
a tasS^ne problem in doing so is *at app^<^on 
vendors typically want to control the way in which tti^e 
So^ takeW^^r example. It may be use^lto^ 
a tax application to access capital gains 'r^forrnaton 
from aCe brokerage application. However, the home 
brokerage application needs to protect the pmracy of 
mtTuTmSporlfolio. Hence, the^appli^h^^^^^^^ 
nSbe given unrestricted access portfoto data from the 
home brokerage application. <„^-pfi to 

[0004] Historically, the task of controlling acc«s^ to 
senrices in computer systems Jjeen h^ed 
through hareiware mechanisms, such as hadw«re 
ciabilities systems. However, such speciaUpu^e 
Slware is not present on all "-"P^'^S "'^ 
Consaquemiy. it is not practical to use such hardwwe to 
SSJdaccess to services for portable appl.catons. 
S asTj^a"* applet which is designed to operate 
across a wide range of computing platforms. 

SUMMARY 



permit, such lhat the access control '"achan sm is tog 
gered by invoking a method on the permit « t^e acc«s 
?s allowed, the method accesses the service by per- 
forming an invocation on a controlled object This con- 
- ?3Sd object includes methods to perfomi the service, 
' Sis ott^erwise protected from the user of the perrT»t 
Another variation of the above embodiment indudes 
receiving, at a pemiit issuing authority, a request for *ie 
^S from an' entity (such as a person, a compiler 
,„ orogram or a computer process) requinng access to *e 
ce If the revest includes valid authorization infor- 
apemirtisissuedtothe entity. Afurthervana- 

tton of the above embodiment includes aeating a <»py 
of the permit and transferring the copy to an entity 
,5 requiring access to the service. 

[00061 Thus, the present invention provides a mettuxl 
for controlling access to a service provided by anrther 
applicatton. This method does not rely on hardware 
access control mechanisms, and hence can be 
20 employed by a portable application aaoss a wide range 

of computing platforms. 



BRIEF DESCRIPnOM OF THE FIGURES 



fOOOSl One embodiment of the present invention pro- 
Sdesamethod and an apparatos for controUing access 
to services provided by other applications. The me*od 
n«tes use of a permit, which includes an access^n- 
trol mechanism that resides in a memory space that^ 
protected from a user of the pem^t The mefrod 
Includes receiving a request for a service through a per- 
mit, the pemiH comprising an object defined an 
object-oriented programming system. In re^nseto 
Z request, the method activates an access confro 
mech^sm within the permit This access 
mechanism controls access to the s«vice and r^ides 
in a memory space that is protected from a user of the 



25 POOTI 

FIG 1A illustrates code modules working together 
within computer system in accordance with an 
embodiment of the present invention. 
30 FIG. IB illustrates a number of computer nodes 
coupled together through a network in accordance 
with an embodiment of the present invention. 
FIQ. 2 illustrates the process of accessing a service 
in accordance with an embodiment of the present 

35 invention. nhiort 
FIG 3 illustrates the structore of a permit obiect 
and'a controlled object 320 in accordance with an 
embodiment of the present invention. 
FIG 4 is a flow chart illustrating the process of ore- 
4o ating a permit object in accordance with an embod- 
iment of the present invention. 
FIQ 5 is a flow chart illustrating the process of 
using a perniit object to access a service in ac^^- 
ance with an embodiment of the present invention. 

^ DETAILED DESCBIPTIOM 



[00081 The following description is presented to ena- 
Se any person sklled in the art to make and use ttie 

5a inverSn and is provided in the cortexld a f«rtoul^^ 
applioaUon and its requirements. Various modificalions 
Sttiedisclosed embodiments will be readily apparerrt to 
those skilled in the art and the seneral pnncp^ 
dSined herein may be applied to other embodimente 

55 and applications without departing from the spirrt ^d 
Spt^thepresentinvention.Thus.thepr^|n.eiv 
tion is not intended to be limHed to the embodimer^ 
shown, but is to be accorded the widest scope consist- 
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ent with the principles and features disclosed herein. 

Distributed Computer Sy stem 

[0009] FIG. 1A Illustrates code modules 102 and 104 
working together within conputer system 100 in accord- 
ance with an embodiment of the present invention. In 
order to work with code module 104. code module 102 
requests services from code module 104. Similarly, in 
order to work with code module 102, code module 104 
requests services from code module 102. Access to 
services between modules 102 and 104 is controlled 
through the permit structure described in more detail 
with reference to FIGs. 3-5 below. 
[0010] For purposes of this detailed description, a 
service is a function made available by a first application 
to other applications. This function may provide the 
other applications with access to data or to corrputa- 
tional resources from the first application. A protected 
memory system is a system that facilitates protection of 
selected regions of memory from an application running 
on the system. 

[0011] F!G. IB illustrates how the present invention 
can be used in a dient-server computer context in which 
a number of computer nodes coupled together through 
a network 1 30 in accordance with an embodiment of the 
present invention. In FIG. 1. servers 110 and 120 are 
coupled to third-party system 140 through network 130. 
Network 130 generally refers to any type of wire or wire- 
less link between computers, inciuding, but not limited 
to. a local area network, a wide area networK or a com- 
bination of networks. In one embodiment of the present 
invention, network 130 includes the Internet Servers 
1 1 0 and 120 can be any nodes on a conputer network 
including a mechanism for servicing requests from a cli- 
ent for conputational or data storage resources. Third- 
party system 1 40 may be any node a computer network 
communicating with servers 110 and 120 that is able to 
download code and/or data from servers 110 and 120. 
[0012] In the embodiment illustrated in FIQ. 1 , server 
110 contains server code module 112, and server 120 
contains dient code nxxiule 122. Server code module 
1 1 2 and client code module 122 include modular pieces 
of code that can operate together on third-party system 
140. The dashed lines in FIG. 1 represent server code 
module 112 and client code module 122 being down- 
loaded onto third-party system 1 40 across network 130. 
This downloading process can take place in a number 
of waya In one embodiment of the present invention, 
server 1 1 0 indudes a web site that can be accessed by 
a user on third-party system 140 to download sender 
code module 112 onto third-party system 140. Corre- 
spondingly, server 120 includes a web site that can be 
accessed by a user on third-party system 140 to down- 
load dient code module 122 into third-party system 1 40. 
In another embodiment server code module 112 and 
client code module 122 are not downloaded across net- 
work 130. Instead, they are transferred from servers 



110 and 120, respectively, to third-party system 140 by 
way of computer storage media, such as a computer 
disk. 

[001 3] Once server code module 1 1 2 and client code 
5 nxxJule 122 are located on third-party system 140. they 
can be integrated to work together as is illustrated in 
FIG. 1 . For example, in providing a service to client code 
module 122. server code module 112 might retrieve 
data from a database for client code module 1 22. Alter- 
10 natively, server code module 112 might perform a com- 
putational operation for dient code module 122. This 
integration process may involve detennining whether 
client code module 122 has been conferred the right to 
access services from server code module 112. In the 
15 reverse direction, this process may involve determining 
whether server code module 112 has been conferred 
the right to access services from client code module 
122. 

20 Process of Accessinq a Sen/lea 

[0014] FIG. 2 illustrates the process of accessing a 
service in accorclance with an embodiment of the 
present invention. FIQ. 2 illustrates interactions 

25 between server gate 202. system 204 and client code 
module 122 (from FIG. 1). Note that the process for 
accessing a service illustrated in FIG. 2 represents only 
one possible method of obtaining access to a service. In 
general, the present invention applies to any pieces of 

30 code working together in a computer system. Server 
gate 202 is a mechanism that provides permits to prop- 
erly authorized requesters. 

[0015] For purposes of this detailed description, a per- 
mit is a token held by an entity, which allows the entity to 

35 access a service. In one embodiment of the present 
invention, a permit indudes an object defined within an 
object oriented programming system that facilitates 
accesses to a collection of services. 
[0016] Server gate 202 includes an access control 

40 mechanism that controls access to services provided by 
server code module 1 12 (from FIG. 1 ). This access con- 
trol mechanism can require varying levels of autherrtica- 
tion from a requester of a permit. In one emtsodiment of 
the present invention, server gate 202 is located within 

43 server code module 112 on third-party system 140. In 
arKither embodiment, server gate 202 is located within 
server 110 itself, and is accessed via communications 
across network 130. System 204 includes a mechanism 
for establishing that client code module 122 is properly 

50 authorized to access services provided by server code 
module 1 12. To this end. system 204 is inplemented in 
a number of ways. In one emkxxliment. system 204 is 
implemented by code that Is part of third-party system 
140. In another embodiment system 204 may be imple- 

55 merited as part of server code module 1 1 2 within third- 
party system 140. 

[0017] The process illustrated in FIG. 2 operates as 
follows. Client code module 122 is assumed to already 
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exist within third-party system 1 40. In order to access a 
desired service, clierrt code module 122 requests a 
"ticket" for a "role" to access a collection of services 
from server code module 112. A role defines a set of 
operations to be performed by server code module 112. 
Certain roles may be more limited than other roles. For 
example, if server code module 1 12 maintains a compu- 
ter file system, one role may include only the operation 
of reading a file from the file system. Another more pow- 
erful role may include the operations of reading, writing 
and deleting files from the file system. 
[0018] In response to the request, system 204 exam- 
ines client code module 122. to determine if cliern code 
module 1 22 includes proper authorization for the role. In 
one embodiment of the present invention, this examina- 
tion includes examining a certificate chain. This process 
is described in more detail in a coiDending European 
Patent Application No., entitled "Controlling Access to 
Services Between Modular Applications." correspond- 
ing to U.S Patent Application Serial No. 09\ 106, 567., 
which is hereby incorporated by reference in order to 
describe this process. 

[001 9] If client code module 1 22 is properly authorized 
for the role, system 204 issues a ticket for the role, and 
this ticket is given to clierrt code module 122. Next, client 
code module 122 passes the ticket to server gate 202. 
Server gate 202 checks the ticket to ensure that the 
ticket is valid, if it is valid, server gate 202 sends a per- 
mit for the sen/ice to client code module 122. This per- 
mit allows diertt code module 122 to access the 
sendees defined by the role. In one embodiment of the 
present invention, this permit is an object defined within 
an object-oriented programming system. This object 
allows dient code module 122 to perform a set of meth- 
ods that conrprise the role. After the permit is serrt, 
server gate 202 invalidates the ticket so that it cannot 
be used again. Since dient code module 1 22 remains in 
possession of the permit dient code module 1 22 will be 
able to access services using the permit, and hence, no 
longer needs the ticket. 

Permit Object 

[0020] FiG. 3 illustrates the structure of a permit 
object 300 and controlled object 320 in accordance with 
an embodiment of the present invention. Permit object 
300 is typically held by a client code module, such as cli- 
ent code nxxJule 122 (from FIG. 1). which requires 
access to services provided by a server code nxx^ule, 
such as server code module 1 12 (from FIG. 1). Server 
code module 112 maintains controlled object 320. 
which contains code and data used to inplement the 
services. Note that the embodiment illustrated in FIG. 3 
is implemented through objects defined within an 
object-oriented programming system. However, the 
invention is not limited to object-oriented programming 
systems. 

[0021 ] Permit object 300 indudes a number of compo- 



nents including controlled object pointer 302, boolean 
vector 304. method-0 pointer 306, method-1 pointer 
308, method-N pointer 310. permit creation method 
312. permit expiration information 314 and permit log 
5 316. 

[0022] Controlled object pointer 302 points to control- 
led object 320, which is maintained by server code mod- 
ule 112, and thereby allows the holder of permit object 
300 to access services associated with controlled 

TO object 320 within server code module 112. Controlled 
object pointer 302 is stored in a memory that area that 
is protected from accesses by client code module 1 22. 
Client code module 122 cannot directly read or modify 
controlled object pointer 302. Client code module 122 

75 cannot access controlled d3ject 320 directly. In order to 
access controlled object 320. client code module 122 
must ask the system to access controlled object 320 
through controlled object pointer 302. Similarly, the 
other data items within permit object 300 are protected 

20 so they cannot be directly read or modified by client 
code module 122. This memory protection ensures that 
dient code module 122 nuast access services associ- 
ated with controlled object 320 by asking the system to 
access the services. This enables the system to restrict 

25 access to the services in a manner that is specified by 
the permit. 

[0023] As mentioned above, this type of menwry pro- 
tection can be provided by using the Java^ program- 
ming language and supporting interfaces. The Java™ 

30 programming language supports memory protection 
down to the object level. Under the Java model, the only 
way to access data within an object is by invoking meth- 
ods supported t}y the object Data within an object is 
othenvise protected from memory references - through 

35 a stray pointer for example. Since the Java™ program- 
ming language can be ported across a wide range of 
computing platforms, this object level memory protec- 
tion can be provided across a wide range of connputing 
platforms. However, note that it nray be possible to get 

40 around the protection mechanism by attacking the inter- 
face between the Java programming language and the 
operating system on a particular conrputing platform. In 
order to prevent this type of attack, the Java™ memory 
protection scheme can be extended into the hardware 

45 of a confuting platform. 

[0024] Boolean vector 304 contains entries corre- 
sponding to methods provided by controlled object 320. 
These methods innptement the services assodated con- 
trolled object 320. If an entry indudes an "ALLOWED" 

50 value, this indicates that the hdder of penmit object 300 
is allowed to access the corresponding method that 
implements the service from controlled object 320. tf the 
entry includes a "NOT ALLOWED" value, this indicates 
the holder of the permit is not allowed to access the cor- 

55 responding method. In this way, permit object 300 spec- 
ifies which services the holder of the permit is allowed to 
access. Since boolean vector 304 is located in pro- 
tected memory, a holder of permit object 300 cannot 
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m(xlify bcx3lean vector 304 to gain unauthorized access 
to a service. Note that there are nnany possible ways to 
indicate that particular methods are not allowed. In 
another embodiment, methods within permit object 300 
are coded to call a corresponding method in controlled 5 
object 320. Othenwise. they are coded to indicate that 
the method is not allowed. 

[0025] The methods specified in controlled object 320 
are accessible through method pointers within permit 
object 300. These method pointers include method-0 10 
pointer 306, method-1 pointer 308 and method-N 
pointer 310. Client code module 1 22 must access meth- 
ods 324, 326 and 328 through these method pointers 
306, 308 and 310. Method-0 pointer 306 points to 
method-0 324 within controlled object 320. Method-1 15 
pointer 308 points to method-1 326 within controlled 
object 320. Method-N pointer 310 points to method-N 
328 within controlled object 320. These method pointers 
reside in protected menrory so that client code module 
122 must access the methods through the system. 20 
[0026] In the illustrated emtxxiiment. permit object 
300 additionally includes permit creation method 312. 
which allows a holder of permit object 300 to create a 
copy of permit object 300, and to transfer the copy to 
another application. This allows client code module 1 22 25 
to ferm out a sub-task requiring services from controlled 
object 320 to another module. Note that permit creation 
method 312 allows only less powerful copies of permit 
object 300 to be made. In other words, copies of permit 
object 300 can access at most the same methods from 30 
controlled object 320. and possibly fewer methods. 
[0027] Permit object 300 additionally includes permit 
expiration information, which specifies some type of 
lifespan limitation for the permit. In one embodiment, 
this is accomplished by specifying a certain time period as 
during which the permit is valid. In another embodiment, 
this is accomplished by requiring that the system first 
check in a central database to see that the permit 
remains still valid. 

[0028] Permit object 300 also includes permit log 316. 40 
which records a log of access requests to permit 300. 
This log can be used for security purposes to monitor 
how permit object 300 is being used. Alternatively, a log 
of access requests can be maintained within controlled 
object 320. 45 
[0029] Controlled object 320 contains data 322, which 
is used by methods 324. 326 and 328 to implement 
services associated with controlled object 320. For 
exanple, data 322 may contain file system data and 
methods 324, 326 and 328 may specify file system so 
operations. 

Permit CreatiniTi 

[0030] FIG. 4 is a flow chart illustrating the process of 55 
creating a permit object in accordance with an embodi- 
ment of the present invention. This flow chart describes 
in more detail the operations performed by server gate 



202, which were described previously with reference to 
FIG. 2 above. The system starts at state 400 and pro- 
ceeds to state 402. In state 402, client code module 122 
performs an invocation on server gate 202 to make a 
new permit As mentioned above, this invocation 
includes a ticket for a role as a parameter. The system 
then proceeds to state 404. In state 404, server gate 
202 autfierrticates the ticket, and if it is valid, server gate 
202 makes a new permit object 300. This process may 
include locating a controlled object 320 to associate 
with permit object 300. or if necessary, making a new 
controlled object 320 within server code module 1 12. 
The system next proceeds to state 408. In state 408, 
controlled object pointer 302 (from FIG. 3) is assigned 
to point to controlled object 320. The system next pro- 
ceeds to state 410. In state 410. the system sets access 
control flags (entries in boolean vector 304) to specify 
which methods the holder of the permit is allowed to 
invoke. The system next proceeds to state 410. In state 
410. penmit object 300 is returned to dient code module 
122. The system next proceeds to state 414. which is an 
end state. 

Use of Permit Ob|ect 

[0031] FIG. 5 is a flow chart illustrating the process of 
using a permit object to access a service in accondance 
with an embodiment of the present invention. The sys- 
tem starts at state 500 and proceeds to state 502. In 
state 502, client code module 122 (from FIG, 1) invokes 
a metiiod on permit object 300 (from FIG. 3). The sys- 
tem proceeds to state 504. In state 504, the system 
checks access control flags corresponding to the 
method- This entails looking up an enti-y in boolean vec- 
tor 304 corresponding to the invoked method. If this 
access control flag indicates the method is allowed, tfie 
system proceeds to state 506. Othenwise. the system 
proceeds to state 510. 

[0032] In state 506 the access is allowed, so the sys- 
tem invokes the appropriate method on permit object 
300, which causes a corresponding method to be 
invoked on controlled object 320 with the appropriate 
parameters. The system next proceeds to state 508. In 
state 508, the system waits for the invocation to com- 
plete, and then returns a result to client code module 
1 22. The system next proceeds to state 512, which is an 
end state. 

[0033] In state 510. the method is not allowed. In this 
case, the system indicates to client code module 122 
that the method Is not allowed. This can be done in a 
number of ways. In one embodiment of the present 
inverrtion, the system causes an exception to occur in 
the execution stream of a processor perfbmiing the 
method invocation. In another embodiment, tiie system 
sets a global variable to indicate that tfie attempted use 
of permit object 300 failed. In yet another embodiment, 
tiie invocation to permit object 300 returns a NULL 
valua The above process is repeated for successive 
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invocations on pernnit object 300. 
[0034] The foregoing descriptions of ennlxxliments of 
the invention have been presented for purposes of illus- 
tration and description only. They are not intended to be 
exhaustive or to limit tiia invention to the forms dis- s 
closed. Accordingly, many modifications and variations 
will be apparent to practitioners skilled in the art 

Claims 

10 

1 . A method for controlling access to services in a pro- 
tected memory system, comprising: 



2. The method of daim 1, wherein the access control 
mechanism (500) provides access to the service by 
performing an invocation (506) on a controlled 30 
object (320), the controlled object including a 
method (324-328) to perform the service, and oth- 
envise being protected from the user of the permit 

3. The method of claim 1 or claim 2, further compris- 3S 
ing if the access is not allowed, indicating (510) to 

an entity requesting the service that tiie access to 
the service is not allowed. 

4. The method of claim 1 or claim 2, wherein the per- 4o 
mit (300) is defined within the Java™ programming 
language and supporting interfaces. 

5. The metiiod of any one of claims 1 to 4, wherein 
data (322) protected by the permit (300) can only 4S 
be accessed through methods (306-310) invoked 

on the permit. 

6. The method of any one of claims 1 to 5. further 
comprising: so 

receiving, at a permit issuing authority, a 
request for the permit from an entity requiring 
access to the service: and 

if the request includes valid authorisation infor- ss 
mation, issuing the permit (412) to the entity. 

7. The metiiod of any one of claims 1 to 6. further 



comprising creating a copy of the permit (300) and 
transferring ttie copy to an entity requiring access to 
tiie service. 

8. The metiiod of claim 7, wherein the copy of the per- 
mit allows access to fewer services than the permit 
(300) that it was copied from. 

9. The method of any one of claims 1 to 8. further 
comprising determining whether the permit has 
been revoked before accessing the service, and 
been revoked, indicating (510) the access is not 
allowed. 

10. The method of any one of claims 1 to 9, further 
comprising recording the access request in a log 
(31 6) associated with the permit 

11. The method of any one of claims 1 to 10. wherein 
activating tine access control mechanism includes 
detennining (314) whetiier tiie permit has expired. 

12. The metiiod of any one of claims 1 to 1 1, wherein 
the access control mechanism includes a pointer 
(302) to the controlled object (320). tiie pointer 
residing in the memory space that is protected from 
the user of the permit. 

13. The mettiod of any one of claims 1 to 12. wherein 
tiie access control mechanism includes a method 
(324-328) to be invoked to perform the service, 
wherein if access is not allowed, tiie method (324- 
328) does not perform tiie service, but instead indi- 
cates (510) that access to tiie service is not 
allowed. 

14. The method of any one of claims 1 to 13, wherein 
the access control mechanism includes a variable 
(304) associated with a method to be invoked to 
perform the service, wherein the variable indicates 
whether the access is allowed. 

15. A computer readable storage medium storing 
instructions tiiat when executed by a computer 
cause the computer to perform a method for con- 
trolling access to services in a protected memory 
system, comprising: 

receiving a request for a service through a per- 
mit, the permit comprising an object (300) 
defined within an object-oriented programming 
system; 

in response to the request, activating an 
access comrol mechanism (500) wfthin the per- 
mit, the access control mechanism controlling 
access to the service and residing in a memory 
space that is protected from a user of the per- 
mit such that the access control mechanism is 



receiving a request for a service tiirough a per- 
mit, the permit comprising an object (300) is 
defined within an object-oriented programming 
system: 

in response to the request, activating an 
access control mechanism (500) within the per- 
mit, the access control mechanism controlling 20 
access to the service and residing in a memory 
space that is protected from a user of the per- 
mit, such that the access control mechanism is 
triggered by invoking (502) a metiiod (306-31 0) 
on the permit; and 2s 
if the access is allowed, accessing the service. 
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triggered by invoking (502) a method (306-310) 
on the permit: and 

if the access is allowed, accessing the service 
by performing an invocation (506) on a control- 
led object (320), the controlled object including s 
a method (324-328) to perform the service, and 
othenwise being protected from the user of the 
permit 

1 6. An apparatus for controlling access to services in a io 
protected memory system, conprising: 

a permit means through which a user can 
access a service, the permit means optionally 
comprising an object (300) defined within an is 
object-oriented programming system; 
an access control means (500) within the per- 
mit the access control means controlling 
access to the service and residing In a memory 
space that is protected from a user of the per- 2o 
mit, such that the access control means is trig- 
gered by invoking (S02) a method (306-310) on 
the permit; and 

a request processing means, in communication 
with the permit means, that is configured to 2S 
receive an access request for the service 
through the permit means, and to activate the 
access control means. 

1 7. The apparatus of claim 1 6. wherein the access con- 30 
trol means (500) is configured to provide access to 
the service by performing an invocation (506) on a 
controlled object (320), the controlled object includ- 
ing a method (324-328) to perform the sen/ice, and 
othenwise being protected from the user of the per- as 
mit (300). 

18. The apparatus of daim 16 or claim 1 7. wherein the 
request processing means is configured to indicate 
(51 0) that the access to the service is not allowed if 40 
the request processing means determines that the 
access is not allowed. 

19. The apparatus of any one of claims 16 to 18, 
wherein the access control means (500) includes at 45 
least one method (324-328) to be invoked to per- 
form the service. 

20. The apparatus of any one of claims 16 to 19. 
wherein the permit (300) is defffied within the so 
Java™ programming language and supporting 
interfacea 

21. ThB apparatus of any one of claims 16 to 20. 
wherein data (322) protected by the permit (300) ss 
can only be accessed through methods (306-310) 
invoked on the permit. 



22- The apparatus of any one of claims 1 6 to 21 , further 
comprising a permit creation mechanism (400) that 
receives a request for the permit (300) from an 
entity requiring access the service, and if the 
request includes valid authorisation information, 
issues (412) the permit to the entity. 

2a TTie apparatus of any one of claims 1 6 to 22, further 
comprising a permit copying mechanism that Is 
configured to create a copy of the permit (300) and 
to transfer the copy of ttie permit to an entity requir- 
ing access to the service. 

24. The apparatus of any one of claims 16 to 23, 
wherein the permit copying mechanism is config- 
ured to produce the copy of the permit that allows 
access to fewer services than the permit (300) it 
was copied from. 

25. The apparatus of any one of claims 16 to 24, 
wherein the request processing means is config- 
ured to determine (504) whether the permit has 
been revoked before accessing the service. 

26. The apparatus of any one of claims 1 6 to 25, further 
comprising a log (316). associated with the permit, 
to record access requests. 

27. The apparatus of any one of claims 16 to 26, 
wherein the request processing means is config- 
ured to detemiine (314) whether the permit has 
expired. 

2a A data structure contained in a computer readable 
storage medium for controlling access to services 
in a protected memory system, the data structure 
comprising: 

an access control mechanism (500) within the 
data structure, the access control mechanism 
controlling access to the service and residing In 
a memory space that Is protected from a user 
of a permit (300), such that the access control 
mechanism is triggered by invoking (502) a 
method (306-310) on the permit; and 
an access control indicator (304) within the 
data structure, the access control indicator 
specifying services the user can access, the 
access control indicator being protected from 
modification by the user. 

29. The data structure of daim 28. wherein the access 
control mechanism (500) indudes a pointer to 
code(324-328) that implements the service, the 
pointer residing In the memory space that is pro- 
tected from the user. 

30. The data structure of claim 28 or claim 29, wherein 
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the access control indicator (304) includes a varia- 
ble associated with a service, wherein the variable 
indicates whether access to a corresporxling serv- 
ice is allowed. 

5 

31. A computer program or applet encoding a set of 
computer instructions for controlling access to serv- 
ices in a protected memory system, which when 
running on a conrqouter is adapted to perform the 
method of any one of claims 1 to 14. io 



IS 



20 



25 



30 



35 



40 



45 



SO 



55 



EP0 965 917 A1 




■ COMPUTER 
SYSTEM 
100 ' 



FIG. 1A 




9 



EP0 965 917 A1 



CLIENT 

SERVER CODE 
GATE SYSTEM MODULE 

202 204 122* 





REQUEST TICKET FOR ROLE 




i 

ISSUE TICKET FOR ROLE 




> 


PASS TICKET TO 
SERVER GATE 






SEND PERMIT TO ACCESS 
RESOURCE THROUGH ROLE 




> 



FIG. 2 



10 



EP0 965 917 A1 



^ PERMIT OBJECT 
f 300 







CONTROLLED 
OBJECT POINTER 
302 






BOOLEAN VECTOR 
INDICATING 
ALLOWED METHODS 
304 






METHOD-0 POINTER 
306 






METHOD-1 POINTER 
308 






• 
• 






METHOD-N POINTER 
310 






PERMIT CREATION 
METHOD 
312 






PERMIT EXPIRATION 
INFORMATION 
314 






PERMIT LOG 
316 







CONTROLLED OBJECT 
320 



DATA 
322 



METHOD-0 
324 



METHOD-1 
326 



METHOD-N 
328 



FIG. 3 



11 



EP0 965 917 A1 



C START N 
400 ^ 



1 1 

INV( 
SERVE! 
4( 


r , 

DKE 

RGATE 

)2 






MAKE 
PERMIT 
4( 


NEW 
OBJECT 
}4 



LOCATE CC 
OBJECT OR 
CONTROLL 
4( 


»NTROLLED 
MAKE NEW 
ED OBJECT 
)6 







ASSIGN POINTER IN 
PERMIT OBJECT 
TO POINT TO 
CONTROLLED OBJECT 
408 



SET ACCESS CONTROL 

FLAGS TO INDICATE 
METHODS THE ROLE IS 
ALLOWED TO INVOKE 
410 



RETURN PERMIT 
OBJECT 
412 



FIG. 4 



12 



EP0 965 917 A1 



C START \ 
5Q0 J 



CLIENT CODE 
INVOKES A METHOD 
ON PERMIT OBJECT 
502 



SYSTEM, 
CHECKS ACCESS 
CONTROL FLAG 
CORRESPONDING TO 
METHOD 
504 



METHOD NOT ALLOWED 



METHOD ALLOWED 



CALL CORRESPONDING 

METHOD IN 
CONTROLLED OBJECT 
-PASS PARAMETERS 
506 



SIGNAL CLIENT THAT 
METHOD 
NOT ALLOWED 
510 



RETURN 
RESULT 
508 



/" END \ 



FIG. 5 



13 



EP0 965 917 A1 



European Patent 
Office 



EUROPEAN SEARCH REPORT 



Appltcitlon Number 

EP 99 20 1908 



DOCUMEMTS CONSIDERED TO BE RELEVANT 



Category 



Citation of document with indication. whetB appropriata. 
of relevant passages 



Relevant 
to claim 



CLASS1RCAT10N Of THE 
APPLICATION (lnt.CI.6) 



GRITZALIS S ET AL: "SECURITY ISSUES 
SURROUNDING PROGRAMMING LANGUAGES FOR 
MOBILE CODE: JAVA RM VS. SAFE-TCL" 
OPERATING SYSTEMS REVIEW (SI60PS), 
vol. 32. no. 2, 1 April 1998 (1998-04-01), 
pages 16-32, XP000766954 

* page 19, left-hand column, paragraph 1 - 
page 22, left-hand column, paragraph 4 * 

* page 26, right-hand column, paragraph 3 

- page 27. left-hand column, paragraph 2 * 

* page 28. left-hand column, paragraph 1 - 
right-hand column, paragraph 2 * 

WALLACH D S ET AL: "Extensible security 
architectures for Java" 
PROCEEDINGS OF THE ACM SYMPOSIUM ON 
OPERATING SYSTEMS PRINCIPLES . 1997 , pages 
1-26 14, XP002101681 

* page 5. line 7 - page 7, line 11 * 

* page 8, line 9 - page 10, line 13 * 

* page 14, line 1 - line 14 ♦ 

N. ISLAM ET AL: "A Flexible Security 

Model for Using Internet Content" 

IBM : DEVELOPER : JAVA OVERVIEW : LIBRARY 

- PAPERS, 'Online! October 1997 (1997-10), 
XP002n5800 

IBM Thomas J. Watson Research Center 

Retrieved from the Internet: 

<URL : http : //www . s of tware . i bm . com/devel oper 

/I Ibrary/f lexsecurity/> 

•retrieved on 1999-09-17! 

* page 4 * 

* Introduction; figure 2 * 

* page 7, paragraph on Java Implementation 



-/- 



1-31 



G06F9/46 
G06F1/00 



1-31 



TECHNICAL REL03 
SEARCHED (lnt.CI.6> 



1-31 



G06F 



The present search report has been drawn up for aJI claims 



Plaeief sMcft 

THE HAGUE 



DM of compttfon of th« mrcti 

20 September 1999 



Powell, D 



CATEQORY OF CITED DOCUMENTS 

X : paitlalany rtl«vant ir taken alon* 

r : pantciiany ratovant if combined wrth anothar 

(tocumant ol the aama catogory 
A : twhnological background 
O : non-writtan disctoeura 
P : (ntarmadlaia documont 



T ; maery or princ^la mdartyfng th» invention 
E : oarUaf patant documant but pUtMshad on, or 

ofttr tha fiinq data 
D : document cttad In tna application 
L : documant cttad for othar reasons 



& : msmdar of tha eame patent family. corrsBpondlng 
documerU 



14 



EP0 965 917 A1 



European Patent 
Office 



EUROPEAN SEARCH REPORT 



Appl(c«tlon Numb«r 

EP 99 20 1908 



DOCUMENTS CONSIDERED TO BE RELEVANT 



Category 



Citation of document with Indtcatton, where approprfaia, 
of relevant passages 



Relevant 
to claim 



CLASSJfTCATlON OF THE 
APPLICATION (lnt.Cl.fl) 



EP 0 813 133 A (IBM) 

17 December 1997 (1997-12-17) 

* the whole document * 

BLAZE M ET AL: "DECENTRALIZED TRUST 
MANAGEMENT" 

PROCEEDINGS OF THE 1996 IEEE SYMPOSIUM ON 
SECURITY AND PRIVACY. OAKLAND. CA. , MAY 6 
- 8, 1996, 

no. SYMP. 17, 6 May 1996 (1996-05-06), 
pages 164-173, XP000634842 
INSTITUTE OF ELECTRICAL AND ELECTRONICS 
ENGINEERS ISBN: 0-7803-3527-9 

US 5 677 952 A (ROGAWAY PHILLIP W ET AL) 
14 October 1997 (1997-10-14) 



1-31 



TECHNICAL FIELDS 
SEARCHED <lnt.CI.6) 



The present search report has been drawn up for all ctaJnis 





0«1« otcompMon of Ih* sMich 


ExBiTknsr 


THE HAGUE 


20 September 1999 


Powell , D 



CATEGORY OF CITED OOCUMEMTS 

X : parttcuarty r«l«vant IT tatwn aton* 

Y : partioJaiiy retcvant tf combifwd with anothar 

documant of mo aama catagtMy 
A : toctmologlcaltMckground 
O ; non-wTitlan disdoaur* 
P : Intarmedtata document 



T : theofy or prtnc^la undarlying tha Irwantlon 
£ : aarttar patart documant but pU}K8had on, or 

anarmamtng data 
O : dooumont cited tn tha application 
L : documant dtad for othar raasons 



& : membor of tha sama palent family, corraspondlng 
documant 



15 



EP0 965 917 A1 



ANNEX TO THE EUROPEAN SEARCH REPORT 
ON EUROPEAN PATENT APPLICATION NO, 



EP 99 20 1908 



THis annex lists th« patent (amily membersrelating to the patani documents cited in the above-mentioned European search report. 

The members are as contained in the European Patent Office EDP file on , . , 

The European Patent Otfica is in no way liable for these particulars which are merely ^en for the purpose of informaton. 

20-09-1999 



Patent document 
cited in search report 



Publication 
date 



Patent family 
member(s) 



Publication 
date 



EP 0813133 



17-12-1997 



JP 10091427 A 



10-04-1998 



US 5677952 



14-10-1997 



US 
EP 
JP 
SG 
US 
US 



5454039 
0658022 
7199808 
44363 
5675652 
5835597 



26-09-1995 
14-06-1995 
04-08-1995 
19-12-1997 
07-10-1997 
10-11-1998 



2 



ui For more details about this annex : see Official Journal of the European Patent Office. No. 12/82 



16 



